查看原文
其他

Linux TraceEvent - 我见过的史上最长宏定义

理查德 Linux阅码场 2021-01-31

TraceEvent是内核中一种探测的机制,据说在不使能的时候是没有损耗的。据说使用起来挺简单,但是要看懂着实需要花些力气。

例子

从例子中学习,一般都是比较好的方法。内核开发者也比较nice,在内核源码samples/trace_events目录下就有这么一个例子。

其中文件一共有三个:

这个例子以内核模块的形式存在,所以只要执行make就可以编译完成。

总的来说,要定义和使用tracepoint,只要做两点。

  • 用TRACE_EVENT来定义一个新的tracepoint

  • 在需要的地方,使用函数trace_XXX打印输出

有了例子我们就要跑一跑,来看看如何使用的。

首先我们要编译出我们的例子,这时候需要加上打开两个编译配置

  • CONFIG_SAMPLES

  • CONFIGSAMPLETRACE_EVENTS

编译

make M=samples/trace_events

然后加载这个例子模块

modprobe trace-events-sample

因为用户接口在debugfs上,所以还要确保debugfs挂载了。

mount -t debugfs none /sys/kernel/debug/

此时我们就能在 /sys/kernel/debug/tracing/events/sample-trace/ 目录下看到该模块创建好的trace event了。

接下来,我们就可以打开这个探测时间,并且查看探测的输出了。

cd /sys/kernel/debug/tracing

echo 1 > events/sample-trace/enable

cat trace

echo 0 > events/sample-trace/enable

通过cat trace观察,可以看出系统运行时的一些状态。

让我们进一步再来看看events/sample-trace这个目录:

可以看到

  • 目录名称sample-trace由TRACE_SYSTEM这个宏定义,所以通过查找这个宏,就能知道有多少events的大类

  • 每一个TRACE_EVENT都有一个自己的目录

源文件中trace_XXX的函数就是执行探测记录的地方了。那么这些函数是怎么定义的呢?

TRACE_EVENT定义

看完了例子,我们就该看代码实现了。讲真,这是我见过的最长的宏展开了。之前在qemu上看到的那个hmp-command和这个比起来简直就是个小屁孩。

先来看一下例子中是如何定义一个trace event的。和其他定义不同,定义trace event的定义在头文件,而非源文件。我把trace-events-sample.h文件做一个简要的打开。

中间我省略了很多TRACEEVENT及其变体,每一个TRACEEVENT对应了一个trace point。

可以看到,一个trace event的定义需要涉及到起码两个头文件。

史上最长宏定义

你以为就这么简单吗?当然不是,作为有多年阅读c语言代码的老司机,看到真正的定义,我都差点没有吐出来。。。

好了,不扯淡了。怎么能很好的解释这个宏展开的过程呢?还是用一张图吧。倒吸一口气,准备一次无尽的代码阅读。

终于完了,也不知道有没有漏掉什么。。。大家如果真的想要看实际代码中展开后的代码,可以运行

make samples/trace_events/trace-events-sample.i

生成的文件是经过预处理后得到的源代码。不过相信我,你可能不太会愿意去看这个(捂脸)

回过头来再看这展开,让我们来总结一下这个过程:

  • 一共包含了两个头文件:linux/tracepoint.h 和 trace/define_trace.h

  • 在trace/definetrace.h中,反复定义了TRACEEVENT且再次包含samples/trace_events/trace-events-sample.h,实现了一个宏定义多次展开的效果

究竟定义了什么?

哪怕有了上面这个图,我想大部分人也是不会去看的。或者说,看了可能也不知道这些宏展开究竟定义了些什么?

帮人帮到底,送佛送到西

既然都帮大家做了宏展开,那我就干脆再用一张图展示一下这么多宏定义究竟定义了些什么。

经过了一番云里雾里的宏展开,实际上就是(主要)定义出了这么一个数据结构 -- traceeventcall。而且这个数据结构关联了几个重要的小伙伴

  • tracepoint

  • trace_event_class

  • trace_event

后续,我们将逐渐看到在初始化和使能的过程中,这些数据结构之间的爱恨情仇。

注册trace_event

有了数据结构,想要使用这个功能,我们能想到的第一步就是要把相关的数据结构注册到某个地方,这样下次才能够被使用到是不是?

这个秘密隐藏在了刚才宏展开的最后一次展开中,大家可以回过去搜“section("ftraceevents") &event##name;”。有内核代码经验的朋友可能已经猜到了,这个意思是我们把一部分的内容强制保存在了一个名为ftraceevents的section中。这些是什么呢?对了就是traceevent_call结构体的指针们。

有了这个信息,我们再来看链接文件的定义:

我们看到ftraceevents这个section被包含在_startftrace_events之间。那就沿着这条线继续。

看到了么?我们依次从_start|stopftraceevents之间拿出每一个内容,再执行eventinit()。而这个类型正好是traceeventcall,和刚才的定义吻合上。

但是eventinit()里面又调用了什么call->class->rawinit(call),这是什么个鬼?别急,这个我已经给你写好了。请跳回到刚才解释traceeventcall的图上找找,这个rawinit函数就是traceeventrawinit。最后这个通过registertraceevent将traceeventcall.event注册到系统中,而这个event的类型是trace_event。

怎么样,是不是够刺激的?

最后我们再来展示一下trace_event注册到系统中后的样子吧。

trace_event结构会在两个地方注册:

  • ftraceeventlist:这个链表用来遍历事件的号码

  • event_hash[128]: 这个哈希表用来查找

有没有看到其中funcs的成员第一个是之前定义的 tracerawoutput_##name?我猜这个就是最后输出到trace文件的代码,你觉得呢?

好了,数据结构注册完了,接下来是什么呢?

注册traceeventcall

在上一节中,我们看到了内核通过编译链接的方法找到了traceeventcall,并且将其中的traceevent注册到了系统中,现在我们来看看traceevent_call是如何注册到系统中的。

这个过程就在event_init()函数下面一点。一共有两个步骤:

  • 添加到ftrace_events链表

  • 添加到trace_array的events

第一步就在刚才的代码片段中listadd(&call->list, &ftraceevents),而第二步则是通过函数_traceearlyaddevents()。

__trace_early_add_events() list_for_each(call, &ftrace_events, list) __trace_early_add_new_event(call, tr)

经过这次注册,将traceeventcall和trace_array连接了起来:

创建tracefs

在使用trace工具的时候,会通过tracefs往某些文件里读写来控制ftrace。trace_event也不例外,所以我们要先来看一下tracefs的构建,为后续的代码阅读做好准备。

说起来这个过程有点绕,因为创建tracefs的地方和刚才那些注册函数不在一个地方(系统启动时)。

具体细节可以看源代码,这里解释两点:

  • createeventtoplevel_files 创建了和trace event相关的根目录的一些文件

  • eventcreatedir则是会对每一个tracearray->events上的traceevent_file调用,创建每个event的目录

而这个tracearray->events则是由, 刚才看到的函数traceearlyaddnew_event()添加的。

初始化过程的梳理

到这里估计你已经晕了,没事我自己写得也晕了。让我们来梳理一下整个初始化过程,明确一下这个注册和tracefs的创建顺序。


  • (1) 从特定的section中拿到traceeventcall数据结构,并注册了trace_event

  • (2) 将traceeventcall添加到了ftrace_events链表

  • (3) 将每一个traceeventcall以traceeventfile的形式添加到trace_array.events

  • (4) 为每一个trace_array.events创建自己的tracefs

废了这么大力气我们都做了什么呢?

关联了tracefs和traceeventfile,也就是我嗯定义的traceeventcall。

所以,每当我们操作一个tracefs文件的时候,后面就对应这相应的traceeventfile和traceeventcall了。


OK, 我们已经为tracefs的操作做好了准备,让我们来看看打开trace event选项时的动作吧。

打开事件

在查看trace文件中的事件记录前,我们需要使能这个事件。

echo 1 > events/sample-trace/enable

所以有个开关来控制事件。而当我们写这个文件的时候,触发到的内核函数就是刚才我们注册tracefs对应的ops中的eventenablewrite。

绕晕了,其实呢就是通过某种方式设置了tracepoint结构体中的funcs成员。刚才我们在traceeventcall结构体中已经看到了tracepoint结构,这次该好好看一眼了。

主角终于登场了,经过这么一顿骚操作后,我们将之前定义好的 traceeventrawevent##name挂到了tracepoint的funcs列表中。当然我还省去了重要的一步--设置key。

输出事件

终于到了最后了。之前说的都是定义和初始化,终于要看到调用的情况了。在例子中我们看到,当我们需要输出一个事件时,就会调用trace_XXX()。这次该轮到它出场了。

先来看看trace_XXX这个函数的定义,它也藏在了我们刚才宏定义的展开中,这次我们仔细看一眼

每次我们调用traceXXX()函数的时候,先检查key是否使能了,如果使能了才继续往下走。接着我们再打开DOTRACE来看看。

联系上上一小节的tracepoint结构体是不是能想到啥?对了,就是遍历tracepoint->funcs数组,然后调用它们。

好了,终于完整的看完了TRACE_EVENT的定义和使用流程。小编累了,大家也累了,今天就到这里吧。

相关阅读推荐:

宋宝华:关于Ftrace的一个完整案例

(END)


更多精彩,尽在"Linux阅码场",扫描下方二维码关注

别忘了点个在看哦

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存